Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware of a marketed product may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
The target computerized system may be a processor, a microprocessor, an electronic circuit, an integrated circuit, a chipset, a computerized device comprising a processor or the like. Testing such devices may comprise one or more pre-silicon stages and/or one or more post-silicon stages.
During the pre-silicon stages, devices are generally tested in a computerized environment simulating the functionality of the devices, such as using HDL simulator, emulators, hardware accelerators, and formal verification tools. In pre-silicon stages, the target computerized system may be described using a descriptive language, such as for example Verilog or VHDL.
Post-silicon validation and debug is the last step in the verification of a computerized device. Post-silicon validation tests occur on the actual devices running at-speed in commercial, real-world system boards, using logic analyzer and assertion-based tools.
In the present disclosure, fabricated target computerized system may be referred to as a circuit, silicon, processor, hardware device or simply device.
The post-silicon stage may refer to a stage once the target computerized system has been fabricated. For example, the post-silicon stage may be after the target computerized system is produced in accordance with a description provided in a descriptive language. It will be noted that the circuit may be different than a finalized product, such as for example comprising only a chip without a casing, being assembled manually, being only partially assembled, a manufactured wafer, or the like.
Modern chips may comprise hundreds of thousands of logic elements and a large number of functionalities and features. It is therefore highly time consuming to thoroughly test the chip, i.e., verify all its areas operate in accordance with the design. On the other hand, due to business-related reasons, it is of high importance that the chip is released on time without undue delays. The time window that is thus available for testing is bounded by receiving the device from the semiconductor fabrication plant (FAB) on the one hand, and the expected release date on the other hand.
It is therefore important to utilize this time window as intensively as possible, and perform the post-silicon validation with enhanced efficiency.
Exercisers are common tools for post-silicon testing. An exerciser is an application that is being loaded to the tested system, generates test cases, executes them, and checks their behavior or results. However, exercisers should be kept as simple as possible due to a number of reasons, including for example the need to debug the target platform, enabling high utilization of the testing platform, or the like.
Since hardware failures are extremely hard to debug, simple software is normally used in order to ease the effort. A complex exerciser may add a redundant level of complexity to the debug process.
An exerciser typically starts executing at an early stage of the bring-up of the device, when no operating system thus no sophisticated debug tools are available, and every operation is performed directly by the device with no abstraction level provided by the operating system.
The exerciser is executed by the device that it tests. Therefore, if the device has a bug, then the bug may be exhibited by the operation of the exerciser itself. It is thus preferable to use an exerciser that performs simple operations for its own functionality and utilizes the device extensively when test cases are executed.
In addition, in order to test some areas of a device, for example floating point operations, it may be required to generate a large amount of test data, including test data that is known to be complex.
However, generating such data is time consuming, which leads to poor utilization of the testing time window, since the tested device is idle while waiting for tests to be generated. Also, if the device is idle for significant part of the time, some errors or problems that occur only after continuous long period of operation of the device may not occur, thus providing non-representative test results. Moreover, generating the data may require complex computations by the exerciser.